Bitcoin is the most valuable and trusted cryptocurrency in the world, and, like other blockchains, it faces a potential future threat from cryptographically resistant quantum computing. From our perspective, making Bitcoin secure against this emerging threat involves more than choosing a quantum-resistant digital signature scheme. We believe a comprehensive transition strategy would ideally protect exposed and newly created funds, fit Bitcoin's scarce block space, preserve independent resource-bounded validation by full nodes, work in institutional custody, support ordinary wallets, and give the ecosystem a credible migration path for coins that cannot or will not move.
Coinbase is one of the largest crypto custodians in the world and holds ~5% of all BTC in existence. For over 13 years, Coinbase has safeguarded digital assets at scale, earning the trust of leading banks, asset managers, hedge funds, and institutions worldwide. Our custody platform combines institutional-grade operational controls with secure key generation, controlled signing workflows, transaction review, continuous monitoring, and tested resilience practices.
Coinbase is preparing our own systems for a post-quantum future, convening discussions with Bitcoin developers and researchers, and supporting open-source work through engineering resources and our participation in the Bitcoin Security Consortium. We want to contribute to the community’s efforts and help create the conditions for careful, sustained progress.
This blog shares technical considerations informed by our work and by the needs we hear from institutional customers. It is intended as an input to an open discussion, not a set of instructions or a final Coinbase position. Some questions, including how to handle abandoned or inaccessible coins, are difficult and deserve thoughtful debate. In our view, that discussion can continue alongside the technical work to add post-quantum signature support to Bitcoin
High-Level Perspective
Coinbase believes that Bitcoin will continue to be the most trusted crypto-currency in a post-quantum world, and we also recognize that the migration will be a challenging, complex, and multi-year process. As the community comes together to work through this challenge, we would like to share our perspective.
Here are a few points we would like to highlight. We elaborate on each in the sections that follow.
Preparing before certainty. We believe it is important to begin preparing well ahead of any CRQC announcement. Bitcoin consensus changes and ecosystem migrations can take years, So it is important that we begin this work now.
Separating the "container" from the signature. In our view, a PQ output type design that allows one or more PQ signature systems to be introduced, replaced, or supplemented without a complete redesign would serve the ecosystem well. P2MR (BIP-360) and P2TRv2 appear to offer this kind of flexibility.
Staged protection. We would welcome an approach in which active wallets can use a PQ-capable or hybrid construction before the final legacy-signature policy is settled. One possible transition design is a 1-of-2 construction: the same funds have two alternative spending paths, one authorized by a classical ECDSA/Schnorr key and one authorized by a PQ key.
Use of state. While stateful PQ signature schemes could be smaller and faster than stateless ones, managing state in digital signatures is notoriously error-prone and could even lead to forgery. If stateful signatures are supported, we think it is important to also have a stateless option available.
Robust implementations. We hope the evaluation process will place strong weight on deterministic, cross-platform verification, constant-time implementations, clear parameterization, and resistance to signing RNG failures.
MPC-friendliness. For Coinbase and many of our customers, MPC-friendliness is an important consideration in the choice of PQ schemes. When implemented effectively, MPC can provide strong protection against key theft, and it is an important layer of defense for large organizations that face constant attacks on their infrastructure.
A path for wallets that migrate late. If Bitcoin eventually limits or ends ECDSA/Schnorr spending, some wallets may not have moved their funds to PQ-safe outputs by then. We believe it would be useful to consider whether and how those users could migrate their funds afterward, while recognizing that the approach and its tradeoffs remain open questions. In our view, that discussion can proceed alongside, and independently of, the technical work to add PQ signature support, so it need not delay progress on that work.
We understand that difficult tradeoffs will have to be made in the post-quantum migration process. We also recognize that there may be no single solution that satisfies all the constraints of the blockchain protocol itself and the needs of every individual user, custodian, and institution. Our goal is to make our needs and concerns visible so they can be weighed alongside everyone else's.
Detailed Needs and Considerations
Output and script architecture
From our perspective, a PQ-capable Bitcoin path would ideally provide:
A commitment structure that hides public keys until needed, avoids a quantum-vulnerable key path, and supports future script leaves or signature algorithms.
Versioning and algorithm identifiers that assign a distinct, unambiguous identifier to every supported PQ scheme and parameter set, without requiring a new output type for every future scheme.
Explicit semantics for key revelation, control blocks, script leaves, sighashes, malleability, and transaction identification.
Consensus and policy limits for witness size, script size, verification work, and worst-case block cost.
A low-friction address format and descriptor representation that wallets, exchanges, hardware wallets, and QR/payment flows can adopt.
BIP-360 proposes P2MR as a Taproot-like commitment with the key path removed and future PQ integration in mind. The current public discussion also includes P2TRv2 and other constructions. We are hopeful the community will arrive at a design that balances long-exposure protection, short-exposure protection, migration usability, privacy, fee cost, script flexibility, and implementation complexity.
Signature-scheme selection
We believe an evaluation and recommendation process that is Bitcoin-specific and reproducible would be most useful. Generic TLS or PKI rankings don't directly translate, because Bitcoin signatures are stored forever and verified by every node.
In our view, a strong candidate list would include finalized standards, candidates progressing through standardization, assumption-diverse alternatives, and Bitcoin-native constructions where they have a credible security and operational rationale. We would like to see the evaluation include ML-DSA, SLH-DSA, FN-DSA when standardized, and serious compact or assumption-diverse candidates that may materially change the tradeoff space. We think SHRINCS is a good fit for this evaluation set as a compact hash-based candidate. Its draft combines a compact stateful FXMSS path with a stateless SLH-DSA-derived fallback, which creates an attractive size/verification tradeoff but also makes signer state, recovery, and implementation assurance central adoption questions.
The criteria we consider most important for evaluating each candidate are:
Signature, public-key, secret-key, and total-spend sizes.
Verification time, tail latency, and batch-verification behavior.
Constant-time and side-channel behavior.
Key generation and signing time, including mass-migration throughput.
RNG dependence, deterministic or hedged signing modes, and fault recovery.
Hardware-wallet, secure-element, HSM, and MPC / threshold signing feasibility.
Security category, cryptanalytic history, assumption diversity, standardization status, and implementation maturity.
Compatibility with committed-key outputs, hybrid transitions, and migration deadlines.
We have found it helpful to look at both raw cryptographic measurements and Bitcoin-derived metrics, such as:
Block capacity and throughput for representative single-signature and multi-party spends.
Fee cost at representative fee rates.
Full-node validation and IBD impact under realistic adoption mixes.
Block-propagation and orphan-risk impact.
Maximum safe PQ work per block under adversarial load.
Time and fee required to migrate a representative vulnerable-UTXO population.
We think a final recommendation would be most actionable if it included a primary choice, a fallback, the reasons for excluding alternatives, and a sensitivity analysis showing how the result changes when block space, security category, implementation maturity, and custody feasibility are weighted differently.
Stateful vs. stateless
While stateful PQ signature schemes could be smaller and faster than stateless ones, managing state in digital signatures is notoriously difficult. State reuse can be catastrophic, leading to immediate forgery.
We are concerned that individuals who self-custody would find it hard to update state in a verifiable manner. They may accidentally reuse state because the old state was lost or never updated properly. They also can't rely on looking at older transactions on the blockchain, because not every signature or state update necessarily makes it on-chain. As a result, they could sign a new transaction without realizing the state is invalid, exposing themselves to forgery and potential loss of funds.
Large exchanges like Coinbase run multiple server instances in different zones that operate independently to process signatures with low latency and high availability. With stateful signatures, a server would need an exclusive read and write lock on a key and its state during signature generation, which would make independent operation infeasible. Schemes such as SHRINCS include mechanisms for managing state, but safe operation depends on knowing whether each state update succeeded and was durably recorded. If an update fails, is lost, or its outcome is unclear, and the system cannot detect that, the signer may unknowingly reuse a state that has already been used. This makes failure recovery and restoring from backup difficult: the system needs a reliable way to establish the current state before signing again.
For these reasons, we would encourage care in how stateful signature schemes are proposed and evaluated. At a minimum, we believe it would help if:
The risks of mismanaging state are made clear upfront.
Wallet providers receive clear guidance on how to manage state.
A stateless fallback path is available, i.e. a stateless-signing-only operation mode.
Transition modes and legacy signatures
We believe it would be beneficial to define transition modes before settling on a final sunset policy. The options we think are worth evaluating include:
PQ-only outputs for users willing to migrate early, e.g. P2QR.
Commit/reveal or other mechanisms that reduce public-key exposure during migration.
A staged policy for new outputs, sends to legacy outputs, and spends from legacy outputs.
Legacy-signature sunset, freeze, rate-limiting, or rescue alternatives.
Behavior of non-upgraded nodes and wallets at every stage.
Dormant, lost, and exposed funds
In our view, legacy funds are best treated as a separate governance and engineering problem.
Some of the considerations we see as relevant include:
P2PK and other outputs with permanently exposed public keys.
Reused keys in otherwise hashed output types.
Dormant but legitimately controlled funds.
Lost keys or inaccessible seeds.
Satoshi-era or otherwise highly concentrated holdings.
The possibility of covert quantum theft before the public learns that a CRQC exists.
Rescue mechanisms based on seed knowledge, hardened derivation, commit/reveal, zero-knowledge proofs, or other knowledge asymmetries. A good discussion can be found here.
Rate-limiting or tripwire mechanisms that preserve early warning without creating an unbounded theft incentive.
We think it is important for any rescue proposal to show that the rescue path is itself PQ-safe and cannot be used by a quantum attacker who only knows an exposed public key. It would also be helpful for proposals to describe what happens when the owner has no recoverable secret, the proof system fails to scale, or the rescue deadline expires.
MPC-friendliness
For Coinbase and many institutional customers, compatibility with MPC signing is an important consideration when evaluating PQ signature schemes. Some schemes, including certain lattice-based approaches, may be more amenable to MPC than others. We believe it would be valuable for Bitcoin’s PQ signature options to include at least one scheme with promising MPC compatibility. This is a consideration for scheme selection, not a request for the Bitcoin community to develop a particular MPC protocol.
We are grateful to the researchers, developers, and builders already working on these questions, and we look forward to continuing to collaborate with the community on Bitcoin's post-quantum future.
